Protocol for communication between access ports and wireless switches

ABSTRACT

A wireless local area network includes access ports which communicate over a wired network with wireless switches which control the access ports and bridge data between portals in the access ports and another network. Code for operating the access ports and for configuring the portals is separately downloaded from the wireless switch. Where an access port includes more than one portal, separate ethernet addresses are assigned to the processor of the access port and to the portals for communications with the wireless switch. The protocol may provide separate sequence numbers for the communications and include a command field.

BACKGROUND OF THE INVENTION

This invention relates to wireless local area networks such as thosefollowing the protocols of IEEE Standard 802.11. In particular thisinvention relates to networks arranged to use wireless switches andaccess ports, such as the networks described in copending applicationSer. No. 09/528,697, filed Mar. 17, 2000, the specification of which isincorporated herein by reference. It should be understood that the term“access port” as used in this application is the commercial name for thedevice referred to as an “RF Port” in the referenced copendingapplication and the term “wireless switch” as used in this applicationis the commercial name for the device referred to as “Cell Controller”in the referenced copending application. The wireless switches of thepresent invention may also correspond to the cell controllers describedin copending provisional application Ser. No. 60/473,755, filed May 28,2003, the specification of which is incorporated herein by reference.

New technologies are currently evolving that make it desirable tosupport different communications protocols and different media using thewireless switches, to interface additional devices to the wired networkcontaining the wireless switch by radio, fiber optics or serial datapaths using other media, including wires.

It is an object of the present invention to provide a new and improvedcommunications format that can accommodate multiple technologies inconnection with communications between a wireless switch and an accessport.

SUMMARY OF THE INVENTION

In accordance with the invention there is provided an improved methodfor configuring access ports in a wireless local area network, wherein awireless switch controls the operation of one or more access ports andmanages data communications with the one or more access ports, andwherein the access ports include one or more portals for communicatingdata to other devices. Software for operation of the access port isdownloaded from the wireless switch. The access port sends datarepresenting the identification of the one or more portals of the accessport to the wireless switch. Data to configure the one or more portalsof the access port is downloaded from the wireless switch to the accessport.

In accordance with the invention there is provided an access portconfigured using the foregoing method.

In accordance with the invention there is provided an improved methodfor communicating in a wireless local area network, wherein a wirelessswitch controls the operation of one or more access ports and managesdata communications with the access ports, and wherein at least one ofthe access ports includes an access port processor and a plurality ofportals for communicating data to other devices. Separate networkaddresses corresponding to the access port processor and the portals areprovided. Messages between the access port processor and the wirelessswitch are sent using a network address corresponding to the access portprocessor; and messages between the portals and the wireless switch aresent using network addresses assigned to the portals.

In a preferred embodiment sequence numbers are assigned to data messagesbetween the access port and the wireless switch, wherein separate seriesof sequence numbers are assigned to each of the access port processorand the plurality of portals. The data messages may have an ethernetformat, including a first ethernet header and a second header, whereinthe ethernet header includes the network address and wherein the secondheader includes the sequence number. The second header may also includea message length field and/or a command field identifying messagedirection and message type. The second header may optionally include acode field indicating a command code for processing data in the message.

In accordance with the invention there is provided a wireless local areanetwork arranged to operate using the method of the invention.

For a better understanding of the present invention, together with otherand further objects, reference is made to the following description,taken in conjunction with the accompanying drawings, and its scope willbe pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example of a wireless localarea network in which the method of the invention may be practiced;

FIG. 2 is a block diagram showing an access port having a single portalin accordance with the prior art;

FIG. 3 is a block diagram of a first access port in accordance with thepresent invention;

FIG. 4 is a block diagram of a second access port in accordance with thepresent invention.

Throughout the figures, unless otherwise stated, the same referencenumerals and characters are used to denote like features, elements,components, or portions of the illustrated embodiments.

DESCRIPTION OF THE INVENTION

As used in this specification the following terms have the followingmeanings:

-   -   An Access Port is a device with an Ethernet connection that        contains at least one Portal.    -   A Portal is any device that is contained in an Access Port that        provides a communication channel to some other device or        network. A portal may be an IEEE 802.11 radio, a radio that uses        some other technology than those described in IEEE 802.11        specifications, or a non-radio device such as a serial channel,        fiber-optic link, etc. An access port may contain multiple        portals for communicating using different protocols, such as        different versions of IEEE 802.11.    -   A Wireless Switch is a device that controls one or more Access        Ports and bridges data between these devices to a different        network, typically a wired Ethernet network.    -   Adoption is the process by which an access port becomes        associated with a wireless switch.    -   A message is a complete unit of data, as seen by the logic that        is to process that data. Size restrictions on a particular        network may force the “message” to be broken into multiple        “packets” or “frames” for transmission on that network.    -   A packet or frame is a single unit of data as handled by a        network. A data unit that is handled as a single entity on one        type of network may have to be broken into multiple units for        transmission on a different type of network. The term “packet”        always refers to the unit of data as seen on the particular        network involved.

Referring to FIG. 1 there is illustrated an example of a wireless localarea network 10 as described in referenced co-pending application Ser.No. 09/528,697, wherein wireless switches 12, 13 (called cellcontrollers in the referenced application) communicate over an ethernet14 with access ports 16, 18 and 20 (called RF Ports in the referencedapplication). The access ports 16, 18 and 20 are arranged to communicatewith mobile units 22, 24 using a protocol such as one or more versionsof IEEE Standard 802.11, or other wireless data communications protocol.

FIG. 2 illustrated an example of an access port 16 as described in thereferenced co-pending application. The access port 16 includes a networkinterface card 26 (NIC), which includes ethernet controller 28 anddigital signal processor 30 (DSP). A radio or RF Module 32 is providedhaving an antenna 34 for wireless communications with mobile units 22,24. As described in the referenced application, lower level media accesscontrol (MAC) functions are performed in the DSP 30 while higher levelMAC functions are performed in the wireless switch 12 or 13 with whichthe access port is communicating.

FIG. 3 illustrates an example of a first access port 18 in accordancewith the present invention which includes two portals. Access port 18includes a NIC 36 having an ethernet controller 38 and a processor 40.Processor 40 may be a digital signal processor or a microprocessor withassociated memory and interfaces for communication with other devices.Access port 18 includes two portals 42, 46, which are designated Radio 1and Radio 2. Each portal has an antenna 44, 48.

FIG. 4 illustrates an example of a second access port 20 in accordancewith the present invention. Access port 20 is the same as access port18, except that the second portal 50 is a fiber optic transducer insteadof a radio and arranged to sent and receive serial data by fiber optictransmission line 48.

The present invention provides a protocol for communication betweenaccess ports 16, 18 and 20 and wireless switches 12, 13. The protocolincludes two versions of some formats, a first version for communicatingbetween a wireless switch 12, 13 and an access port 16 having a singleportal. The second version of the protocol is for communicating betweenwireless switches 12, 13 and access ports 18, 20 having multipleportals. The two versions of the protocol format are compatibly used inthe same system, and many of the formats for the two versions areidentical.

The present invention further provides an arrangement for downloadingruntime code from the wireless switches to the access ports. In the caseof access ports having multiple portals, the present invention furtherprovides an arrangement for configuring the portals of an access port.

In the case of multi-portal access ports, there are preferably multipleMAC addresses assigned to the access port. The first is the MAC addressfor the NIC card and the processor thereon. The remaining MAC addressesare preferably assigned to the portals of the access port. Generally, anoperational access port will preferably have at least two MAC addresses,regardless of the number of portals.

All communication between the Wireless Switch and the Access Portprocessor or Portal within the Access Port uses WISP messages (WISP isan acronym for Wireless Switch Protocol). All fields are in big endian(network order) format. Within each field the highest order bit is shownto the left and the lowest order bit is shown to the right. The WISPmessage format is shown in Table 1.

TABLE 1 WISP Message Format. Ethernet Header WISP Header Message BodyCRC (14 bytes) (6 bytes) (variable length) (4 bytes)

The Ethernet Header portion of the message is the standard IEEE 802.3header, consisting of the destination MAC address, the source MACaddress, and the Ethertype. The Ethertype field may contain theproprietary Symbol Ethertype value of 0x8783 or other value. TheEthernet header is shown in Table 2. The WISP Header is shown in Table3.

TABLE 2 Ethernet Header. size in Byte offset from Field bytes start ofmessage description destination 6 0 MAC address of destination. source 66 MAC address of source. ethertype 2 12 0x8783

TABLE 3 WISP Header. size in byte offset from Field bytes start ofmessage description Command 2 14 command - direction, type, and code(see Table 4 for details) Sequence 2 16 sequence number Length 2 18Message Body length (the number of bytes following this field)

The command field is divided into sub-fields as shown in Table 4 below.

TABLE 4 Command sub-fields. length in bit Field bits number descriptiondirection 1 15 Direction in which message is sent. See followingparagraph. type 3  14-12 Message type (message types are listed in Table5). code 12  11-0 Command code. Codes for types 0, 1, 2, and 3 messagesare listed in Tables 6 through 9, and are described in subsequentsections. The code for type 3 messages is always 0. The diagnosticcommand type is defined in the diagnostics message body. Codes for type6 are TBD.

For messages that are sent to or from an Access Port, the directionsub-field is set to 0 if the message is sent from the Access Port andset to 1 if the message is sent to the Access Port. Type 3 messages areused for hardware diagnostics and may be specified by the devicemanufacturer.

The type sub-field values and meanings are listed in Table 5.

TABLE 5 Type sub-field values. Type Description 0 Management message. 1Wireless Data message. 2 Flow Control message. 3 Diagnostic message. 4Reserved 5 Reserved 6 Inter-Wireless Switch message. 7 Reserved

The initial set of command codes for the management messages is setforth in Table 6. The initial set of command codes for the wireless datamessages is set forth in Table 7. The initial set of command codes forthe flow control messages is set forth in Table 8. The initial set ofcommand codes for the diagnostic messages is set forth in Table 9.

TABLE 6 Type 0 message command code sub-field values. Direction CommandCommand Name Usage 1 0x0001 Configuration Runtime 1 0x0002 Reset Runtime1 0x0003 UpdateTim Runtime 0x0004 undefined 0 0x0005 Ack-old Download 00x0006 Status Runtime 1 0x0006 Heartbeat Runtime 0 0x0007 Hello Download0 0x0008 ConfigMe Runtime 0 0x0009 LoadMe-old Download 0 0x000A Nak-oldDownload 1 0x000B LoadImage-old Download 1 0x000C LoadDone-old Download1 0x000D Parent Download 0 0x000E DeviceInfo Runtime 0/1 0x0015 AckDownload/ Runtime 0 0x0019 LoadMe Download 0/1 0x001A Nak Download/Runtime 1 0x001B LoadImage Download 1 0x001C LoadDone Download all otherundefined values

TABLE 7 Type 1 command sub-field values. Direction Combined ValueCommand Meaning 0 0x1101 (from Access 0x0101 Frame body contains 1 Port)full packet 1 0x9101 (to Access 0x0101 Frame body contains 1 Port) fullpacket 0 0x1103 (from Access 0x0103 Frame body contains Port) 1st of 2fragments of 1 data frame 1 0x9103 (to Access 0x0103 Frame body containsPort) 1st of 2 fragments of 1 data frame 0 0x1104 (from Access 0x0104Frame body contains Port) 2nd of 2 fragments of 1 data packet 1 0x9104(to Access 0x0104 Frame body contains Port) 2nd of 2 fragments of 1 datapacket all other undefined values

TABLE 8 Type 2 command sub-field values. Combined Direction ValueCommand Command Name 0 0x2010 0x0010 UpdateResults 0 0x2011 0x0011DTIM_Poll all other values undefined

TABLE 9 Type 3 command sub-field values. Direction Combined ValueCommand Meaning 0 0x3000 (from Access 0x3000 Diagnostics Response Port)from Access Port to Diagnostics Host 1 0xB000 (to Access 0x3000Diagnostics Command to Port) Access Port from Diagnostics Host

The sequence field is used for multiple purposes. There are alsomultiple sequence number streams for use in different types of WISPmessages. Each stream starts with a value of 0 and increments by one foreach successive message.

The Wireless Switch assigns sequence numbers as follows: for a givenAccess Port, there is one 16-bit sequence number stream used for allManagement messages sent by the Wireless Switch (the same stream is usedregardless of whether the Management messages are addressed to theAccess Port or one of the portals within the Access Port). In addition,there are different 16-bit sequence number streams used to sendimmediate Wireless Data messages to each portal within an Access Port.Immediate Wireless Data messages are those that are sent by the WirelessSwitch to the portal without delay (this includes all directed data aswell as those multicast data frames that match the multicast mask).Another sequence number “stream” is used by the Wireless Switch to sendbulk-delayed Wireless Data messages to a portal. Bulk-delayed messagesare those non-directed Data frames that are stored in the WirelessSwitch until the portal requests them via a DTIM Poll message (i.e. allbroadcasts plus those multicasts that don't match the multicast mask).Each time the Wireless Switch sends bulk-delayed messages, they startwith sequence number 0 and increment by one until all queued messagesare transmitted to the portal that requested them. In response to thenext DTIM Poll, whether it comes from the same portal or a differentone, the sequence numbers in the bulk-delayed Wireless Data messagesstart at 0 again.

The Access Port assigns sequence numbers as follows: the boot codeutilizes a single 16-bit sequence number stream for all messages ittransmits. After a successful download, the Access Port processor uses adifferent 16-bit sequence number stream for all messages it transmits(this currently only includes DeviceInfo messages). Each portal withinthe Access Port uses its own 16-bit sequence number stream for everymessage it transmits, regardless of whether they are Management,Wireless Data, or Flow Control messages.

An Access Port with two portals would deal with the following sequencenumber streams:

-   -   3 transmitted        -   one for all messages sent by boot code        -   one for all messages sent by portal 1        -   one for all messages sent by portal 2    -   4 received        -   one for all Management messages        -   one for immediate Wireless Data messages to portal 1        -   one for immediate Wireless Data messages to portal 2        -   one for bulk-delayed Wireless Data messages to either portal

During executable image downloading the sequence numbers provide a meansof identifying each segment of the downloaded file by incrementing thisvalue for each segment. This ensures that no frames are received out ofsequence.

Sequence numbers are included in non-download management messages mainlyto assist packet flow analysis and debug. Neither Wireless Switches norportals are required to detect and/or reject non-download managementmessages that are received out of sequence.

During runtime the sequence numbers in immediate Wireless Data messagesprovide a means of flow control for 802.11 data frames sent from theWireless Switch to a portal. The Wireless Switch and the portals use theSequence field to reassemble any fragmented packets, as the sequencenumber will remain constant for each fragment of a Wireless Datamessage.

The following provides the details of Management message contents. Manyof the messages follow a format that provides for the possibility ofvariable length fields. The general form of this format is:

Item ID Item Length Data

-   Item IDs are unique single byte values.-   Item Lengths represent the size of the Data field in bytes. Item    Lengths may be fixed or variable.-   Data is the actual data of interest.-   Management frames are frames with type=0.

During Access Port initialization, the Hello message is transmitted onceper second until a Parent reply is received or upon the expiration of apredetermined period of time (e.g., 60 seconds). The Hello messageformat is shown in Table 10, and is used with the Parent message toprovide a way for Wireless Switches to declare their intention to adoptan Access Port. The Hello message has no body.

TABLE 10 Hello message format. size in Byte offset from Field bytesstart of message description Destination 6 0 0xFFFFFFFFFFFF (Broadcastaddress) Source 6 6 Access Port NIC MAC address Ethertype 2 12 0x8783Command 2 14 0x0007 Sequence 2 16 0-65535 Length 2 18 0

The Parent message is sent from a Wireless Switch to an Access Port inresponse to a Hello message. The Parent message is used with the Hellomessage to provide a way for Wireless Switches to declare theirintention to adopt an Access Port.

A Wireless Switch sends a Parent message in response to a Hello messageif the Wireless Switch is configured to do so. The format for the Parentmessage is shown in Tables 11 and 12, the message body consists of theWireless Switch MAC address.

TABLE 11 Parent message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Access Port NIC MAC addressSource 6 6 Wireless Switch MAC address Ethertype 2 12 0x8783 Command 214 0x800D Sequence 2 16 0-65535 Length 2 18 6

TABLE 12 Parent message body. Byte offset from size in start of messageField bytes body description Parent 6 0 Wireless Switch MAC addressAddress

In response to the Parent message, the Access Port sends a LoadMemessage. The message content and format depends on the configuration ofthe Access Port. A first version of the LoadMe message, shown in Table13 is utilized by the DSP-based Access Ports of the type described inco-pending application Ser. No. 09/528,697 and shown in FIG. 2. OtherAccess Ports, particularly access ports having more than one portalutilize the LoadMe message defined in Table 15.

The LoadMe message is sent by an Access Port to request that anexecutable image be downloaded into the Access Port. When an Access Portpowers on, it sends LoadMe messages at 1-second intervals for 10seconds, if there is no response the Access port must reset.

Information in the LoadMe message body is used by the Wireless Switch todetermine whether or not to adopt the Access Port. Information in theLoadMe message may also be presented to the user at the Wireless Switchuser interface, depending on the design of the Wireless Switch.

The LoadMe frame body is made up of a series of Items. Each Itemconsists of a 1-byte ID field, a 1-byte length field, and a variablelength data field. The length field is the total length in bytes of thedata field. The length field is always an even number. If the truelength of a variable length data field is an odd number, then a one bytepad (zero) is added to the end of the data to make the length an evennumber.

Item IDs 1 through 5, described in Table 14 below, must always bepresent in the LoadMe frame. This message may be extended whenappropriate and other Items may be included as needed. The receiver ofthe LoadMe message must ignore all Items that it does not understand.

TABLE 13 First version LoadMe message header. size in Byte offset fromField bytes start of message description Destination 6 0 0xFFFFFFFFEFFF(Multicast address) Source 6 6 Access Port NIC MAC address Ethertype 212 0x8783 Command 2 14 0x0009 Sequence 2 16 0-65535 Length 2 18 Lengthof entire message (= 76)

TABLE 14 First version LoadMe message body. Byte offset from size instart of message Field bytes body Description Reserved 6 0 Unused FragLen 2 6 Length of all data to follow (= 48) ID 0x01 2 + 6 8 Access PortNIC MAC address ID 0x02  2 + 12 16 Access Port Serial number in binaryor ascii ID 0x03 2 + 2 30 Access Port PCB revision number in binary.First byte = major. Second byte = minor. ID 0x04 2 + 2 34 Access PortBoot Loader revision number in binary. First byte = major. Second byte =minor. ID 0x05  2 + 16 38 Access Port model number in ascii.

A second version of the LoadMe message, for use by advanced AccessPorts, such as the multiple portal access ports shown in FIGS. 3 and 4,is shown in Tables 15 and 16.

TABLE 15 Second version LoadMe message header. size in Byte offset fromField bytes start of message description Destination 6 0 0xFFFFFFFFFFFF(Broadcast address) Source 6 6 Access Port NIC MAC address Ethertype 212 0x8783 Command 2 14 0x0019 Sequence 2 16 0-65535 Length 2 18 Variable(see Table 16)

TABLE 16 Second version LoadMe message body. Length of data Item IDfield in bytes Description 0x01 6 Access Port NIC MAC address 0x02variable Access Port Serial number in binary or ascii. 0x03 2 AccessPort PCB revision number in binary. First byte = major. Second byte =minor.

The Wireless Switch responds to the LoadMe message with a LoadImagemessage, which downloads the operating code for the network interfacecard (NIC) of the access port. For the first version of the LoadMemessage the LoadImage message is described in Table 17 and 18.

The Wireless Switch sends the first LoadImage in response to a LoadMe(if the Wireless Switch determines that it will adopt this Access Port).

When the Access Port responds to the LoadImage with a Ack that indicatesthe next sequence number, the Wireless Switch sends the next LoadImagemessage. When the Access Port responds to the LoadImage with a Nak, theWireless Switch resends the last LoadImage message.

This continues until the entire image has been downloaded.

The last portion of the file is sent in the body of a LoadDone message.This indicates to the Access Port that it has received its entireruntime image.

TABLE 17 First version LoadImage message header. size in Byte offsetfrom Field bytes start of message description Destination 6 0 AccessPort NIC MAC address Source 6 6 Wireless Switch MAC address Ethertype 212 0x8783 Command 2 14 0x800B Sequence 2 16 0-65535 Length 2 18 Lengthof entire message (= 28 + R)

TABLE 18 First version LoadImage message body. Byte offset from size instart of message Field bytes body description Reserved 6 0 Unused FragLen 2 6 Length of all data to follow (= R) Runtime R 8 Block of runtimeimage Image

In response to the second version of the Load Me message the Wirelessswitch sends the LoadImage message in the format specified in Tables 19and 20. As with the first version, the image code may be sent in anumber of fragments with the last fragment indicated to be a LoadDonemessage in the command code.

TABLE 19 LoadImage message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Access Port NIC MAC addressSource 6 6 Wireless Switch MAC address Ethertype 2 12 0x8783 Command 214 0x801B Sequence 2 16 0-65535 Length 2 18 R (see FIG. 20)

TABLE 20 LoadImage message body. Byte offset from size in start ofmessage Field bytes body description Runtime R 0 Block of runtime imageImage

Acknowledgement messages are sent by the access port in response to eachLoadImage or LoadDone message from the wireless switch to the accessport that is successfully received. The first version Ack message isresponsive to the first versions of the LoadImage and LoadDone messagesand is set forth in Tables 21 and 22. The second version responsive tothe second version of the LoadImage and LoadDone messages is set forthin Tables 23 and 24. The sequence number in the Ack is taken from thesequence field of the LoadImage or LoadDone packet header.

TABLE 21 First version Ack message header (Ack from Access Port toWireless Switch). size in Byte offset from Field bytes start of messagedescription Destination 6 0 Wireless Switch MAC address Source 6 6Access Port NIC MAC address Ethertype 2 12 0x8783 Command 2 14 0x0005Sequence 2 16 0-65535 Length 2 18 Length of entire message (= 30)

FIG. 22 Ack message body (Ack from Access Port to Wireless Switch). Byteoffset from size in start of message Field bytes body DescriptionReserved 6 0 Unused Frag Len 2 2 Length of all data to follow (= 2)Download 2 8 Identical to the value Sequence of the Sequence fieldNumber in the header of the received LoadImage or LoadDone message

TABLE 23 Second version Ack message header (Ack from Access Port toWireless Switch). size in Byte offset from Field bytes start of messagedescription Destination 6 0 Wireless Switch MAC address Source 6 6Access Port NIC MAC address Ethertype 2 12 0x8783 Command 2 14 0x0015Sequence 2 16 0-65535 Length 2 18 2

TABLE 24 Second versionAck message body (Ack from Access Port toWireless Switch). Byte offset from size in start of message Field bytesbody description Download 2 0 Identical to the Sequence value of theSequence Number field in the header of the received LoadImage orLoadDone message

A Wireless Switch using the second version sends an Ack when aDeviceInfo packet is successfully processed. The sequence number in theAck is taken from the sequence field of the DeviceInfo packet header.The format for the Ack message from the Wireless Switch to the AccessPort is set forth in Tables 25 and 26.

TABLE 25 Ack message header (Ack from Wireless Switch to Access Port).size in Byte offset from Field bytes start of message descriptionDestination 6 0 Access Port NIC MAC address Source 6 6 Wireless SwitchMAC address Ethertype 2 12 0x8783 Command 2 14 0x8015 Sequence 2 160-65535 Length 2 18 2

TABLE 26 Ack message body (Ack from Wireless Switch to Access Port).Byte offset from size in start of message Field bytes body descriptionDeviceInfo 2 0 Identical to the Sequence value of the Sequence Numberfield in the header of the received DeviceInfo message

Nak messages are sent under the same conditions as Ack messages when aprior message is not successfully received. The first version Nakmessage format is set forth in Tables 27 and 28. The second version Nakmessages from the Access Port to the Wireless Switch are set forth inTables 29 and 30. The Nak messages from the Wireless switch to theAccess Port are set forth in Tables 31 and 32. In connection with Nakmessages the sequence number is taken as the last successful sequencefield incremented by one.

TABLE 27 First version Nak message header (Nak from Access Port toWireless Switch). size in Byte offset from Field bytes start of messagedescription Destination 6 0 Wireless Switch MAC address Source 6 6Access Port NIC MAC address Ethertype 2 12 0x8783 Command 2 14 0x000ASequence 2 16 0-65535 Length 2 18 Length of entire message (= 30)

TABLE 28 First version Nak message body (Nak from Access Port toWireless Switch). Byte offset from size in start of message Field bytesbody description Reserved 6 0 Unused Frag Len 2 2 Length of all data tofollow (= 2) Download 2 8 Equal to the value Sequence of the Sequencefield Number in the header of the received LoadImage or LoadDone messageplus 1

TABLE 29 Second version Nak message header (Nak from Access Port toWireless Switch). size in Byte offset from Field bytes start of messagedescription Destination 6 0 Wireless Switch MAC address Source 6 6Access Port NIC MAC address Ethertype 2 12 0x8783 Command 2 14 0x001ASequence 2 16 0-65535 Length 2 18 2

TABLE 30 Second version Nak message body (Nak from Access Port toWireless Switch). Byte offset from size in start of message Field bytesbody description Download 2 0 Equal to the value of Sequence theSequence field Number in the header of the received LoadImage orLoadDone message plus 1

TABLE 31 Second version Nak message header (Nak from Wireless Switch toAccess Port). size in Byte offset from Field bytes start of messagedescription Destination 6 0 Access Port NIC MAC address Source 6 6Wireless Switch MAC address Ethertype 2 12 0x8783 Command 2 14 0x801ASequence 2 16 0-65535 Length 2 18 2

TABLE 32 Second version Nak message body(Nak from Wireless Switch toAccess Port). Byte offset from size in start of message field bytes bodydescription DeviceInfo 2 0 Equal to the value of Sequence the Sequencefield Number in the header of the received DeviceInfo message plus one

A LoadDone message is sent by the Wireless Switch to the Access Portwith the last fragment of code of the LoadImage message. In connectionwith Access Ports using the first version the LoadDone message isdefined by Tables 33 and 34. The second version of the LoadDone messageis shown in Tables 35 and 36. The LoadDone message contains the lastsegment of image code followed by a 16-bit checksum.

TABLE 33 First version LoadDone message header. size in Byte offset fromField bytes start of message description Destination 6 0 Access Port NICMAC address Source 6 6 Wireless Switch MAC address Ethertype 2 12 0x8783Command 2 14 0x800C Sequence 2 16 0-65535 Length 2 18 Length of entiremessage (= 30 + R)

TABLE 34 First version LoadDone message body. The number of bytesremaining may be zero. Byte offset from size in start of message fieldbytes body description Reserved 6 0 Unused Frag Len 2 2 Length of alldata to follow (= 2) Runtime R 8 Last block of Image runtime image.Checksum 2 R 16-bit, ‘exclusive or’ checksum of the entire downloadedimage file. Big endian. If the total number of bytes in the image isodd, a zero ‘pad’ byte is added to perform the checksum calculation.

TABLE 35 Second version LoadDone message header. size in Byte offsetfrom Field bytes start of message description Destination 6 0 AccessPort NIC MAC address Source 6 6 Wireless Switch MAC address Ethertype 212 0x8783 Command 2 14 0x801C Sequence 2 16 0-65535 Length 2 18 R + 2(see FIG. 3.12a)

TABLE 36 Second version LoadDone message body. The number of bytesremaining may be zero. Byte offset from size in start of message fieldbytes body description Runtime R 0 Last block of runtime Image image.Checksum 2 R 16-bit, ‘exclusive or’ checksum of the entire downloadedimage file. Big endian. If the total number of bytes in the image isodd, a zero ‘pad’ byte is added to perform the checksum calculation.

An Access Port using the second version sends a DeviceInfo packet toreport the combined capabilities of all its portals to the WirelessSwitch. The DeviceInfo message is sent when the Access Port's runtimeimage is loaded and is executing correctly, but before its radios havebeen configured. The DeviceInfo message is broadcast so that allWireless Switches may be aware of the Access Port's radio configuration.

If the Access Port received a Parent response from its Hello message,the Access Port expects an Ack of the DeviceInfo message from its ParentWireless switch (i.e. from the MAC address indicated by the first Parentto reply to the Access Port's Hello message). If the Access Port doesnot see such an ACK within 10 seconds, it will reset and begin sendingHello messages.

If the Access Port did not receive a Parent response from its Hellomessage, the Access Port will send five DeviceInfo messages (once persecond). It will then reset and begin sending Hello messages.

The Body of the DeviceInfo message is made up of a series of items.These items are not guaranteed to be in any particular order, althoughit is suggested that they be placed in numerical order according to thevalue of their ID fields.

The format for the DeviceInfo message is set forth in Tables 37 through40.

TABLE 37 DeviceInfo message header. size in Byte offset from Field bytesstart of message description Destination 6 0 0xFFFFFFFFFFFF (Broadcastaddress) Source 6 6 Access Port NIC MAC address Ethertype 2 12 0x8783Command 2 14 0x000E Sequence 2 16 0-65535 Length 2 18 Variable (see FIG.38)

TABLE 38 DeviceInfo Message Body. length of data item ID field in bytesDescription 0x01 6 Access Port NIC MAC address. 0x02 variable AccessPort serial number in ascii. 0x03 2 Access Port PCB revision number inbinary. First byte = major. Second byte = minor. 0x05 variable AccessPort model number in ascii. 0x06 Variable WISP version in ascii 0x07 6Parent. The MAC address of the first Wireless Switch to respond to theAccess Port's Hello frame. All 0's if no Wireless Switch replied to theHello frame. 0x08 Variable Access Port runtime firmware version numberin ascii. 0x09 2 Number of installed portals (radios). 0x0A 2 Portalindex (0 based). 0x0B 2 Portal type (see FIG. 3.13b). 0x0C variablePortal firmware revision number in ascii. 0x0D 2 Options bit mask (seeFIG. 3.13c). 0x0E 6 Portal MAC address 0x58 1 Number of supported ESSs

Items Oxa, Oxb, Oxc, Oxd, and Oxe above may preferably be repeated (inorder) for each portal on the device.

TABLE 39 Portal Type Codes. Portal Type description 0 IEEE 802.11aradio. 1 IEEE 802.11b DS radio. 2 IEEE 802.11g radio. 3 IEEE 802.11b FHradio.

TABLE 40 Option Bit Mask Definitions. Bit number description 15 Internalprimary antenna installed. 14 External primary antenna installed. 13Internal secondary antenna installed. 12 External secondary antennainstalled.

It is notable that the bits of Table 40 may have meaning only if theAccess Port has the capability to detect the presence of the antenna.Thus, the Wireless Switch must preferably be aware of the Access Port'scapability to detect antennas.

When the Access Port's runtime image is loaded following the secondversion of the protocol and the Access Port has successfully sent aDeviceInfo to the Wireless Switch, but the radio has not beenconfigured, each portal of the Access Port sends the ConfigMe packet toreport its capabilities to the Wireless Switch and to request itsconfiguration. Until a radio has been configured, it sends a ConfigMepacket every 3 seconds for 9 seconds. After which it sends out aConfigMe every 60 seconds until a response if received. When theConfiguration Packet has been successfully received and processed by theradio, the ConfigMe is no longer sent. The radio then begins normaloperation. The format of the ConfigMe message is set forth in Tables 41and 42.

TABLE 41 ConfigMe message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Wireless Switch MAC addressSource 6 6 Radio MAC address Ethertype 2 12 0x8783 Command 2 14 0x0008Sequence 2 16 0-65535 Length 2 18 Variable (see Table 42)

TABLE 42 ConfigMe message body. length of data item ID field in bytesDescription 0x01 6 Access Port NIC MAC address. 0x07 6 Parent. The MACaddress of the first Wireless Switch to respond to the Access Port'sHello frame. 0x0A 2 Portal index (0 based). 0x0B 2 Portal type (seeTable 39). 0x0C variable Portal firmware revision number in ascii. 0x0D2 Options bit mask (see Table 40). 0x0E 6 Portal MAC address. 0x0F 2Total number of buffers available to hold packets awaiting forwarding(transmission, if the Portal is a radio). 0x10 2 Transmit buffer size inbytes 0x11 1 Hop Set (FH port value) 0x12 1 Hop Sequence (FH portcurrent value) 0x13 2 Hop dwell Time (FH port current value

It is noted that the FH portal will preferably send out certainparameters already stored in FLASH configuration memory. Exemplaryvalues are set forth in Table 42 and are Hop Set (values may be 1-3),Hop sequence (values may be 1-max number of channels/3), and hop dwelltime (range 20-1000 in K-usec units).

The Wireless Switch may send a Configuration packet in response to theConfigMe packet or whenever a change in configuration is required.

The Configuration message includes a header shown in Table 43 and ismade up of a variable number of Items. The format of the possibleConfiguration Items is described in Tables 44 to 51. A Portal mustignore any configuration item that it does not recognize.

Configuration messages will generate a Status message if they areprocessed correctly. If the Access Port determines that theConfiguration is erroneous, the Access Port shall reply to theConfiguration with a Status message that indicates the error in theConfiguration Error Type field.

TABLE 43 Configuration message header. size in Byte offset from Fieldbytes start of message description Destination 6 0 Radio MAC addressSource 6 6 Wireless Switch MAC address Ethertype 2 12 0x8783 Command 214 0x8001 Sequence 2 16 0-65535 Length 2 18 Variable (see Table 44)

TABLE 44 Configuration Message Body Item Descriptions. Length of dataItem ID field in bytes description 0x20 2 Configuration sequence number.Incremented for each succeeding Configuration messages sent to aparticular radio. 0x21 variable ESS ID. First byte is ESS index,followed by ESS ID in ascii. 0x22 1 Index of ESS to use in beacons. 0x232 ESS ID activation mask. Bit 0 = ESS 0, etc. If the bit is set, thatESS is active, otherwise it is not active. When an Access Port receivesa Probe for an active ESS, the Access Port will generate a ProbeResponse. When an Access Port receives a Probe for an inactive ESS, theAccess Port will not generate a Probe Response. 0x24 1 Transmit powerlevel. Units in dbm. 0x25 1 Primary channel number. IEEE 802.11bchannels are 1 through 14. IEEE 802.11a channels are 36, 40, 44, 48, 52,56, 60, 64, 149, 153, 157, 161. 0x27 2 Allowed rates mask. (See Table 67for rate mapping.) 0x28 2 Basic rates mask. (See Table 67 for ratemapping.) NOTE: For the Atheros 11a radio there are only twopossibilities for Basic Rates: 6 and {6, 12, 24). For the FH radiopossibilities for Basic Rates are 1 only, 2 only, or 1 & 2. 0x29 1 CCAlevel. 0x2A 1 CCA mode (algorithm 1, 2, 3, or 4). 0x2B 2 RTS threshold(0-2437). A zero value causes an RTS frame to precede every MSDU. 0x2C 2ESS Options. First byte is ESS index. Second byte is a capability mask.See FIG. 3.15b. 0x2D 2 Broadcast ESS enable mask. Bit 0 = ESS 0, etc. Ifa bit for a specific ESS is set, the radio will respond to probes usinga broadcast ESS with a probe response. 0x2E 2 Option mask. See Table 45for option definitions. 0x2F variable Allowed channels (one byte each).This is the list of channels that will be scanned during an Auto ChannelScan procedure. Channels in this list will be binary numbers as listedbelow. The selected channel will be returned to the Wireless Switch in aStatus message. IEEE 802.11b channels are 1 through 14. IEEE 802.11achannels are 36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157, 161. 0x30 1Time (in seconds) to scan any channel for the presence of radar beforeusing. 0x31 2 Time (in TU or kilo micro- seconds) of quiet period ifBluetooth coexistence is enabled. 0x32 1 Time (in 64 microsecond pieces)of guard band if Bluetooth coexistence is enabled. 0x33 2 Beaconinterval in TU (kilo microseconds). 0x34 1 DTIM interval, measured inbeacon intervals. 0x35 variable Reserved for IEEE 802.11i securityelement. 0x36 variable Country information element. See Tables 47 and 480x37 17  Load balance element. See Table 49. 0x38 variable WiFiProtected Access (WPA) Element. First byte is ESS index. Following bytesare WPA security element. See Table 50. 0x39 1 Hop Algorithm (0 - IEEE,1 - Hop Delta) 0x42 1 Hop Set (1, 2, or 3) 0x43 1 Hop Sequence (indexinto hop table possible values are 1 through max # of channels/3) 0x44 2Hop Dwell Time (Kilo microseconds) 0x45 Variable Hop channel table

-   -   Note: For the FH port the Country information element could be        used to set up First channel and Max Channel for the Hop Table.        Therefore First Hop Channel and Maximum number of channels where        not inserted to Configuration message body.

TABLE 45 ESS Options Item Bit Definitions. bytes description 1 ESS index(0-3). 1 Bit mask. Bit 0 = WEP enabled.

TABLE 46 Option Mask Bit Definitions. bit description 0 Secure beacon -if set, the ESS is not transmitted in the beacon. 1 Automatic channelscan - enabled if bit is set. 2 Short preamble - enabled if bit is set.3 Rogue AP detection - enabled if bit is set. 4-7 Antenna diversitysettings. See Table 51 for definitions 8 Scan channels for radar beforeusing.

TABLE 47 Country Information Element header. field bytes descriptionm_byElementId 1 ELEMENT_ID_COUNTRY_INFO = 7 m_byLength 1 Variable - seebelow. m_CountryCode 2 Country ID padded with trailing spacesm_indoor_outdoor 1 Indoor vs Outdoor setting

TABLE 48 Country Information Element channel descriptor. field bytesdescription m_byMinChannel 1 first channel for country m_byMaxChannel 1number of channels m_byMisc 1 maximum tx power in dBm (signed) Note thatthe number of the above channel descriptors is variable for each country(for each Country Information Element header). Each country has as manyof the above three-byte channel descriptors as there are non-contiguousbands - or have different power levels within a contiguous group ofchannels. For 802.11a, contiguous means “monotonically increasing”.Thus, for example, the entire U-NII lower band (with a maximum of 10 dBmpower) could be specified as: m_byMinChannel = 36 m_byMaxChannel = 4m_byMisc = 10 The above values for the channel descriptor would indicatethat channels 36, 40, 44, and 48 are allowed. For 802.11a all channelsmonotonically increase by four. For 802.11b all channels monotonicallyincrease by one.

TABLE 49 Load Balance Element. field bytes description m_byElementId 1ELEMENT_ID_LOAD_INFO = 173 m_byLength 1 length is fixed at 15 m_byOUI 30x00a0f8 (Symbol) m_woAssociatedMUs 2 total associated MUs m_woKBPS 2kilo bytes per second m_woPacketsPS 2 packets per second m_woTXPower 2transmit power m_dwNetTime 4 network time

TABLE 50 WiFi Protected Access (WPA) Element. field bytes descriptionESS index. 2 Index of ESS being referred to. ID 1 221 decimal or 0xDDlength 1 variable OUI 3 0x00, 0x50, 0xF2 OUI Type 1 0x01 version 2 TBDMC Suite 4 Multicast suite selector. (For selector details, see SSNdocumentation.) UC Suite count 2 Number of unicast suite selectors. UCSuite list 4*N Unicast suite selectors. Auth Suite count. 2 Number ofauthentication suites. Auth Suite list 4*N Authentication suiteselectors.

TABLE 51 Antenna Diversity Settings. bit description 4 Receive onPrimary Antenna 5 Receive on Secondary Antenna. 6 Transmit on PrimaryAntenna 7 Transmit on Secondary Antenna

The configuration sequence number is incremented by the Radio when allconfiguration processing is complete. The radio sends this value to theWireless Switch in a Status packet to indicate that all changesspecified have been successfully made. If the radio receives aConfiguration packet with the previously seen sequence number the radiowill ignore that packet.

The initial Configuration packet sent to a radio must contain all of theconfiguration information that is required for radio operation. If afield is absent, the radio will use a default value. SubsequentConfiguration packets must contain Items that are to be changed, but maycontain Items that have not changed.

Every 5 seconds, a configured Radio sends a Status message to theWireless Switch to announce that it is still operational. AdditionalStatus packets can be sent at any time as needed so that the WirelessSwitch may recognize significant changes. Examples of significantchanges are the auto channel scan feature completes, an 802.11a portaldetects radar on its current channel, or an erroneous Configurationmessage is received as indicated by the Configuration Error Type field.When this occurs, the Configuration message that contained the error, isnot effective.

The Status packet is also used to send statistical and statusinformation to the Wireless Switch. These Items can be defined in thefuture.

The body of this message consists of a series of Items. Each Itemconsists of a 1-byte Item ID, a 1-byte length, and a variable lengthdata field. The length field is the total length in bytes of the datafield. The Status message format is shown in Tables 52, 53 and 54.

TABLE 52 Status message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Wireless Switch MAC addressSource 6 6 Radio MAC address Ethertype 2 12 0x8783 Command 2 14 0x0006Sequence 2 16 0-65535 Length 2 18 Variable (see Table 53)

TABLE 53 Status Message Body. item ID bytes meaning description 0x50 2Auto channel 0xFFFF => ACS in process scan. 0xFFFE => ACS complete; newconfiguration pending. Else => Current channel 0x51 2 ConfigurationConfiguration sequence complete. number of active configuration 0x52 4Cumulative Number of CRC errors since CRC Errors last reset (ifavailable) 0x53 1 Radar Detect The existence of this field means thatradar was detected. The one-byte data field indicates the channel onwhich the radar was detected. 0x54 2 Configuration 0 means no errors.Non Error Type zero indicates an error number. See Table 54 for a listof error numbers. 0x59 1 Seconds since The number of seconds lastheartbeat since the last heartbeat message was received by the AccessPort

During normal operation, the selected channel item is the channelcurrently in use by the radio. The value 0xffff indicates that AutoChannel Scan is in progress. The value 0xfffe indicates that AutoChannel Scan has completed and the radio is waiting for a newconfiguration.

TABLE 54 Error numbers. error number meaning 0x01 ACS bit set. Nochannels indicated. 0x02 Channels inconsistent with Country InformationElement

The Wireless Switch sends a Heartbeat message to each Radio each secondto indicate to the Radio that the Wireless Switch is still operational,to keep the network time synchronized and to update load balance data

This load balance data becomes part of the Load Balance Element in thebeacon and probe response RF packet. The requirement for the 1-secondupdate time is to keep the network time synchronized. The Heartbeatmessage format is shown in Tables 55 and 56.

TABLE 55 Heartbeat message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Radio MAC address Source 66 Wireless Switch MAC address Ethertype 2 12 0x8783 Command 2 14 0x8006Sequence 2 16 0-65535 Length 2 18 19

TABLE 56 Heartbeat Message Body. item ID bytes description 0x37 17 Loadbalance element. See Table 49.

The purpose of UpdateTIM packet is to update the Partial Virtual Bitmapfield of the beacon for a Radio and to update the bitmap offset of thebitmap control field. The rest of the fields in TIM element are filledin by the Radio.

The TIM map is compiled by the Wireless Switch based on the trafficcurrently stored for each PSP MU that is associated through this radio(if any). The length field of the fragment control header indicates thetotal length of the element.

Format for the UpdateTIM message is shown in Tables 57 and 58. The firstbyte of the body in the packet will indicate the bitmap offset forbitmap control. The rest is the Partial Virtual Bitmap to be part ofeach beacon.

TABLE 57 UpdateTIM message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Radio MAC address Source 66 Wireless Switch MAC address Ethertype 2 12 0x8783 Command 2 14 0x8003Sequence 2 16 0-65535 Length 2 18 Variable (see Table 58)

TABLE 58 UpdateTIM Message Body. Byte offset from size in start ofmessage field bytes body description BSS Index 2 0 Index of BSSID thatis requesting its bulk- delayed Wireless Data messages. Valid range =0-3 (4 BSSIDs supported) Bitmap 1 2 Bitmap offset to be Offset includedin the TIM information element, as defined by 802.11 Partial variable 3Partial virtual bitmap Virtual to be included in the Bitmap TIMinformation element, as defined by 802.11

The purpose of Reset packet is to reset the Access Port. It may bedirected to either the Access Port NIC MAC address or to a Portal MACaddress. When directed to the Access Port NIC MAC address, the Resetpacket has the same effect as toggling power at the Access Port—theAccess Port will revert back to its initialization procedure.

When directed to a Portal MAC address, the Portal will revert to theConfigMe stage, sending ConfigMe messages until a Configuration isreceived from the Portal's Parent Wireless Switch. Portals other thedestination portal shall not change their operating state. The headerfor the Reset message is shown in Table 59. This message has no body.

TABLE 59 Reset message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Access Port NIC MAC addressOR Portal MAC address Source 6 6 Wireless Switch MAC address Ethertype 212 0x8783 Command 2 14 0x8002 Sequence 2 16 0-65535 Length 2 18 0

In the following discussion the term “radio” is used to refer to aPortal (radio or other entity) that resides within an Access Port, evenin the case where the Access Port only consists of one radio and thesame MAC address is used for both Access Port and radio.

Each message to be sent to a radio by a Wireless Switch is sentencapsulated in one or more Wireless Data Packets. Each time theWireless Switch creates a Wireless Data Packet—without fragments—inwhich to encapsulate a message, it increments the value of the sequencefield in that Wireless Data Packet by 1. If the message must befragmented, the sequence number is the same value for each fragment ofthe message. The radio remembers the value of the sequence field in thelast of the Wireless Data Packets that contained each frame to betransmitted. The sequence numbering is independent for each radio withinan Access Port. As soon as possible after the radio forwards a framethat it received from a Wireless Switch, it reports the value of thesequence field that was in the Wireless Data Packet that originallycontained that frame back to the Wireless Switch in the Results1 orResults2 fields as described below.

There are two methods that a radio can use to report to the WirelessSwitch the sequence fields of frames most recently forwarded. Bothmethods involve filling in the Tx Results fields of a message that issent to the Wireless Switch. The first method is to fill in the TxResults1 and Tx Results2 fields in a Wireless Data Packet that containsa message received by the radio and destined for the Wireless Switch.The second method is to create an UpdateResults message, fill in one ormore Tx Results fields as necessary, and send it to the Wireless Switch.The only purpose of this message is to report the results fields to theWireless Switch. Each radio must implement a mechanism to report theresults of forwarded messages to the Wireless Switch as quickly aspossible.

When a fragmented message received by the Access Port from the WirelessSwitch has been successfully transmitted by the Access Port, thesuccessful result is indicated as described above. In this case, justone Results indication is sent from the Access Port to the Wirelessswitch—even though the Access Port received two frames (two fragments)for the message.

The format for a wireless data message from the access port to thewireless switch is set forth in Table 60 and 61. When the access port isconfigured using the first version of the protocol and having only oneaccess port, the Radio MAC address is the address of the Access PortNIC.

TABLE 60 Wireless Data message header (Data from Radio to WirelessSwitch) size in Byte offset from Field bytes start of messagedescription Destination 6 0 Wireless Switch MAC address Source 6 6 RadioMAC address Ethertype 2 12 0x8783 Command 2 14 0x1101 (if frame bodycontains a complete packet) 0x1103 (if frame body contains 1^(st) of 2fragments) 0x1104 (if frame body contains 2^(nd) of 2 fragments)Sequence 2 16 0-65535 NOTE: The Sequence value shall be constant for agiven pair of Wireless Data messages of Command types 0x1103 and 0x1104(i.e. fragments share a single sequence number) Length 2 18 D + 14 (seeTable 61)

TABLE 61 Wireless Data message body (Data from portal to WirelessSwitch) Byte offset from size in start of message field bytes bodyDescription Flow 2 0 Future sequence number Control corresponding toWindow the last immediate Wireless Data message that can be received,given the currently available buffers in the portal Tx Results 1 4 2Allows results of a completed frame transmission to be piggybacked ontoa received frame (see Table 62 for details) Tx Results 2 4 6 Allowsresults of a 2^(nd) completed frame transmission to be piggybacked ontoa received frame (see Table 62 for details) Rx Data 2 10 Informationabout the received frame (see Table 63 for details) Channel 2 12 Channelon which the data frame was received (see Table 65 for details) DataFrame D 14 802.11 data frame received by the portal

The format for the TxResults 1 and TxResults 2 fields is set forth inTable 62.

FIG. 62 Format of the Tx Results1 and Tx Results2 fields length field(bits) bit # Description ok 2 31-30 0 = tx results invalid 1 = framesent successfully 2 = frame failed: excessive retries 3 = frame failed:lost rate 5 29-25 data rate at which packet was transmitted (ratesspecified in Table 64) retries 5 24-20 total number of retries fortransmitted packet channel 8 19-12 Channel on which frame wastransmitted seq 12 11-0  transmission sequence number modulo 4096 NOTE1: although the corresponding sequence field in the WISP header is 16bits, only the lower 12 bits are supplied in this field since this isadequate for the Wireless Switch to uniquely identify the results.

When the radio has received a message that is to be forwarded to theWireless Switch, it fills in the TxResults1 and TxResults2 fields of theframes that contain the encapsulated message as follows, depending onwhat has or has not already been reported to the Wireless Switch:

If all data sent by the Wireless Switch to the radio to be forwarded hasbeen forwarded and the results have been reported to the WirelessSwitch, both fields are set to zero.

If only 1 message sent from the Wireless Switch has been forwarded andnot reported, the TxResults1 field is filled in with informationregarding the last (or only) fragment of that message and TxResults2 isset to 0.

If more than 1 message sent from the Wireless Switch has been forwardedand not reported, the TxResults1 is filled in with information regardingof the oldest unreported message and the TxResults2 field is filled inwith information regarding of the next oldest unreported message.

A portal can report lost frames by setting the “ok” subfield equal to 3,the “seq” subfield to the sequence number that was lost, and setting therest of the subfields to 0.

If the Access Port has forwarding results ready to report, but there areno received frames waiting to be sent to the Wireless Switch, the radiowill create and send UpdateResults messages to the Wireless Switch soonafter the transmit results are known to the Access Port. The TxResults1and TxResults2 fields are filled in as described above. How long aportal hangs on to unreported results before creating and sending anUpdateResults message is implementation dependent, but in general thistime should be minimized.

The results reported to the Wireless Switch may not be in sequence. Eachradio is free to transmit Data frames in whatever order it deems mostefficient, but transmit results must be sent back to the Wireless Switchin the same order as the results become known to the radio.

The Rx Data field is filled in the body of the Wireless Data Packet thatcontains the last fragment of that message using the format of Table 63.The RSSI sub-field contains the relative signal strength with which themessage was received (if the Portal is a radio), as reported by thesupporting hardware. The rate sub-field contains the encoded data rateof the received message (if the Portal is a radio). Encoding of the datarate is shown in Table 64 below. The format for the channel field isshown in Table 65.

TABLE 63 Format of the Rx Data field. length field (bits) bit #description RSSI 8 15-8  receive signal strength indicator 3 7-5 Notused rate 5 4-0 receive data rate (see Table 64)

TABLE 64 data rate values. value rate (MBPS) 0 1 1 2 2 5.5 3 6 4 9 5 116 12 7 18 8 22 9 24 10 36 11 48 12 54

TABLE 65 Format of the channel field. length Field (bits) bit #description channel 8 7-0 Channel this frame was received on Reserved 815-8  Not used

The format for the header field and body of a data message from thewireless switch to a radio is shown in Table 66 and 67.

TABLE 66 Wireless Data message header (Data from Wireless Switch toportal) size in Byte offset from Field bytes start of messagedescription Destination 6 0 Radio MAC address Source 6 6 Wireless SwitchMAC address Ethertype 2 12 0x8783 Command 2 14 0x9101 (if frame bodycontains a complete packet) 0x9103 (if frame body contains 1^(st) of 2fragments) 0x9104 (if frame body contains 2^(nd) of 2 fragments)Sequence 2 16 0-65535 NOTE: The Sequence value shall be constant for agiven pair of Wireless Data messages of Command types 0x9103 and 0x9104(i.e. fragments share a single sequence number) Length 2 18 D + 14 (seeTable 67)

TABLE 67 Wireless Data message body (Data from Wireless Switch toportal) Byte offset from size in start of message field bytes bodydescription Start Rate 2 0 Initial transmission rate to attempt, encodedas described in Table 4.5. Allowed 4 2 Bit map of allowed Ratestransmission rates (see Table 68) Transmit 2 6 Information about Controlthe frame to be transmitted (see Table 69 for details). Reserved 6 8Reserved for future growth. NOTE: The number of bytes in any WirelessData message type, prior to the actual data frame, is consistentregardless of the message direction. Data Frame D 14 802.11 data frameto be transmitted by the portal

The bit map values for any transmit rate, including the Allowed Ratesfield in Table 67, is shown below in Table 68. The top row is the bitnumber. The bottom row is the data rate in megabits per second.

TABLE 68 Rate bit map. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 54 48 36 2422 18 12 11 9 6 5.5 2 1

The Transmit Control field is set forth in Table 69. The priority fieldis intended to allow flexibility in support of Quality of Servicemechanisms. Where such mechanisms are not in place the field is set tozero.

The group field specifies the priority group to which this messagebelongs.

The relationship between Priority Group and Priority is as follows: Eachpriority group may be sub-divided into up to 16 priorities. Any messagein one priority group has priority over any message in a lower-numberedpriority group, regardless of the value of their respective priorityfields.

The profile field specifies a retry algorithm. More specifically, the RFPort uses this value to determine the following information for eachtransmission:

-   -   Maximum contention window (CW) for each transmission attempt    -   Maximum number of retries to be attempted    -   When to lower the Tx rate

The retry algorithm to be used is not specified by the protocol.Instead, it is up to the implementation to define the appropriatetransmit profile for each of the five profile types.

TABLE 69 Transmit Control field. Length field (bits) bit # descriptionpriority 8 15-8  0 group 4 7-4 priority groups: 0 = normal (lowestpriority group) 1 = DTIM/BCMC 2 = management/voice (highest prioritygroup) profile 4 3-0 tx profile: 0 = BC/MC 1 = Data 2 = Voice Data 3 =Voice MC 4 = Management Frame

Flow control allows for the efficient movement of data from a WirelessSwitch to a portal. It also ensures that data will not be sent to aportal that doesn't have room for it. There are two distinct types ofdata that flow control applies to: immediate and bulk-delayed. Each typeis handled with a different method of flow control.

Immediate Wireless Data messages are flow-controlled via the Sequencefields in their headers, and the Flow Control Window field in the bodiesof upstream (i.e. from portal to Wireless Switch) Wireless Data,UpdateResults, and DTIMPoll messages. The Flow Control Window fieldallows a portal to advertise to the Wireless Switch how much room it hasleft to accept additional Wireless Data messages. This room is expressedin terms of a “window” of sequence numbers, where the Flow ControlWindow value is the last sequence number that can be accepted. As aportal transmits data via RF, it frees up additional buffer space andsubsequently advertises a new window in the next Wireless Data,UpdateResults, or DTIMPoll message it transmits. The advertised windowwill always be either equal to or larger than the last advertised window(excluding the 16-bit wraparound case).

Bulk-delayed Wireless Data messages are flow-controlled via the DTIMPollmessage. This message is sent prior to an imminent DTIM time, andsignals the Wireless Switch to send all buffered non-directed data tothe portal that requested it, up to the limit specified within theDTIMPoll message. The sequence numbering for bulk-delayed Wireless Datamessages is separate from immediate Wireless Data messages, and eachportal must maintain a separate memory area for each data type. Receiptof (and subsequent RF transmission of) bulk-delayed Wireless Datamessages have NO impact on the value of the Flow Control Window field.

The UpdateResults message is sent to the Wireless Switch by a Radio wheninformation is available regarding the status of one or more completeddata forward (transmit) operation(s) and no data that has been receivedis pending to be sent to the Wireless Switch. The Tx Results fields arefilled in as described above. The TxResults 1 and TxResults 2 fields arealways included in this message, even if there is only one result toreport (in that case, the Tx Results2 field would be invalid).Additional TxResults can be appended to this message as necessary.

This message also serves to update the Wireless Switch with the latestflow control information. The format for the UpdateResults message isset forth in Tables 70 and 71.

FIG. 70 UpdateResults message header. size in Byte offset from Fieldbytes start of message description Destination 6 0 Wireless Switch MACaddress Source 6 6 Radio MAC address Ethertype 2 12 0x8783 Command 2 140x2010 Sequence 2 16 0-65535 Length 2 18 2 + (N * 4), where N is thenumber of Tx Results included in the body of this message

FIG. 71 UpdateResults message body. Byte offset from size in start ofmessage Field bytes body Description Flow 2 0 Future sequence numberControl corresponding to the Window last immediate Wireless Data messagethat can be received, given the currently available buffers in theportal Tx 4 2 Allows results of a Results 1 completed frame transmissionto be reported (see Table 62 for details) Tx 4 6 Allows results of a2^(nd) Results 2 completed frame transmission to be reported (see Table62 for details) Reserved 4 10 Unused Number 2 14 Number of additional ofResults Tx Results fields included in this message (doesn't include thetwo Tx Results fields above: they are always present). Valid range:0-100 Tx 4 16 Results for first Results_1 extra unreported frame (seeTable 62 for details) Tx 4 16 + 4*(N − 1) Results for Nth Results_Nextra unreported frame (see Table 62 for details). NOTE: The maximumvalue of N is 100.

The radio sends theDTIM_Poll message to the Wireless Switch to requestthat any stored (buffered) broadcast or multicast messages be sent. Theamount of time between the DTIM_Poll and DTIM time is implementationdependant. When the DTIM time occurs, the radio will transmit anybroadcast or multicast messages that it has received since the lastDTIM.

This message also serves to update the Wireless Switch with the numberof currently available transmit buffers (non-DSP) for this radio.

This message can be used to send any previously unreported TxResults tothe Wireless Switch. Zero, one, or two valid TxResults may be included,but the TxResults 1 and TxResults 2 field are always present even ifthey don't contain valid data. The format for the DTIM_POLL message isset forth in Tables 72 and 73.

TABLE 72 DTIM_Poll message header. size in Byte offset from Field bytesstart of message description Destination 6 0 Wireless Switch MAC addressSource 6 6 Radio MAC address Ethertype 2 12 0x8783 Command 2 14 0x2011Sequence 2 16 0-65535 Length 2 18 8

TABLE 73 DTIM_Poll Message Body. Byte offset from size in start ofmessage Field bytes body description Flow 2 0 Future sequence numberControl corresponding to the Window last immediate Wireless Data messagethat can be received, given the currently available buffers in theportal Tx 4 2 Allows results of a Results 1 completed frame transmissionto be reported (see FIG. 4.2 for details) Tx 4 6 Allows results of a2^(nd) Results 2 completed frame transmission to be reported (see FIG.4.2 for details) Reserved 4 10 Unused Last 2 14 Value of the Sequencefield Sequence in the header of the last received immediate WirelessData message Portal 2 16 Old or New. Type 0 => old (DSP based) 1 => newCapacity 2 18 Bulk-delayed Wireless Data message transmit capacity. Ifthe portal type field above is 0, then this value is in bytes. If theportal type field above is 1, then this value is in buffers. BSS 2 20Index of BSSID that is Index requesting its bulk- delayed Wireless Datamessages. Valid range = 0-3 (4 BSSIDs supported)

The process by which an Access Port becomes associated with (or adoptedby) a Wireless Switch is called the Access Port Adoption Process (APAP).Some WISP messages are used only during this Adoption Process.

The following illustrates the possible normal initialization messagesequences between a Wireless Switch and an Access Port.

The first section describes a normal successful download between theWireless Switch and a multi-portal access port. The second sectiondescribes the message exchanges between a multi-portal access port andthe Wireless Switch when no Wireless Switches are configured to adoptthe port. The third section describes the message exchanges between aDSP based Access Port, as shown in FIG. 2, and a Wireless Switch.

The following table summarizes message exchanges when the Access Portbegins the sequence with a Hello message and at least one WirelessSwitch is configured to adopt the Access Port.

Next Desti- Expected Message Source nation Message Notes Hello AccessBroad- Parent Port cast Parent Wireless Access LoadMe The FIRST ParentSwitch Port message received by the Access Port determines the AccessPort's Parent. LoadMe Access Broad- LoadImage Port cast Load- WirelessAccess Ack Access Port Image Switch Port accepts Load- Image messagesonly from it's Parent. Ack Access Wireless LoadImage LoadImage, Ack PortSwitch or sequence LoadDone continues until file download completes asindicated by LoadDone Load- Wireless Access Device- Done Switch PortInfo Device- Access Broad- Ack DeviceInfo Info Port cast informs allWireless Switches of the capabilities of the Access Port. Ack WirelessAccess ConfigMe Access Port Switch Port accepts Ack only from itsParent. ConfigMe Access Wireless Config- Port Switch uration Config-Wireless Access Status uration Switch Port Status Access Wireless Normaloperations Port Switch begin after this point

The following summarizes message exchanges when NO Wireless Switches areconfigured to adopt the Access Port.

Next Expected Message Source Destination Message Notes Hello AccessBroad- Parent The Access Port Port cast sends ten Hello messages. Noresponse is received from any Wireless Switch. LoadMe Access Broad-LoadImage The Access Port Port cast gets its firmware download from thefirst Wireless Switch to reply to the LoadMe. Load- Wireless Access AckImage Switch Port Ack Access Wireless LoadImage LoadImage, Ack PortSwitch or sequence LoadDone continues until file download completesindicated by LoadDone Load- Wireless Access Device- Done Switch PortInfo Device- Access Broad- DeviceInfo Info Port cast informs allWireless Switches of the capa- bilities of the Access Port. TheDeviceInfo message is sent five times. The portal then resets.

The following summarizes message exchanges when an Access Port beginsthe initialization sequence with a LoadMe message rather than a Hellomessage.

Next Expected Message Source Destination Message Notes LoadMe- AccessBroad- LoadImage- The Access Port old Port cast old gets its firmwaredownload from the first Wireless Switch to reply to the LoadMe. Load-Wireless Access Ack-old Image- Switch Port old Ack-old Access WirelessLoadImage- LoadImage, Ack Port Switch old or sequence LoadDone-continues until old file download completes as indicated by LoadDoneLoad- Wireless Access Device- Done- Switch Port Info old Device- AccessBroad- Ack The Parent Info Port cast field of the DeviceInfo messagedoes not exist. If a Wireless Switch chooses to Adopt this Access Port,the Wireless Switch responds to the DeviceInfo with an Ack. Ack WirelessAccess Device- This Ack Switch Port Info informs the Access Port thatthe Wireless Switch is now its “Parent”. Device- Access Broad- Ack TheParent Info Port cast field of this DeviceInfo message now contains theMAC address of the Wireless Switch that sent the above Ack. Ack WirelessAccess ConfigMe This Ack Switch Port confirms the adoption. ConfigMeAccess Wireless Config- Port Switch uration Config- Wireless AccessStatus uration Switch Port Status Access Wireless Normal Port Switchoperations begin after this point

After each portal is configured, it begins normal operation. Duringnormal operation with no traffic, the Wireless Switch sends a“Heartbeat” message to each portal once per second. The portal sends a“status” message to the Wireless Switch every 5 s.

Access Port Wireless Switch 1) <-- Heartbeat (1) 2) <-- Heartbeat (2) 3)<-- Heartbeat (1) 4) <-- Heartbeat (2) 5) <-- Heartbeat (1) 6) <--Heartbeat (2) 7) <-- Heartbeat (1) 8) <-- Heartbeat (2) 9) <-- Heartbeat(1) 10) <-- Heartbeat (2) 11) Status (1) --> 12) Status (2) -->

If any portal misses the Heartbeat for 10 s, the Access Port resets andstarts again at phase 1.

During normal operation, if an 802.11a radio detects radar, transmissionon the current channel will cease. The 802.11a portal will send a Statusmessage with a “radar detect” indication. At this point, normalforwarding operations will cease. The Access Port will remain in thisstate (as if no Active ESS's are defined) until another Configurationmessage is received from the Wireless Switch. The next Configurationmessage will determine the next action taken by the Access Port. Thenext Configuration message may indicate that the Access Port shallperform ACS (described below). The Configuration message may simplyindicate which channel to use. In this case, the Access Port shallcontinue normal operation on the channel indicated in the Configurationmessage.

The Switch may direct the Access Port to perform ACS at any time. Thefollowing steps are involved in the ACS process:

The Switch sends a Configuration message to Access Port with theAutomatic Channel Scan bit set. The ACS bit is in the Option Mask field(Element ID 0x2E) of the Configuration message. When this message isreceived by the Access Port, all normal forwarding operations willcease. This will be operationally identical to having no Active ESS. TheHeartbeat and Status message exchanges will continue during ACS.

In the same Configuration message, the Allowed Channels Field (0x2F)will define the list of channels (one or more) to use in the process.

When the Access Port begins the process, the Access Port will send aStatus message to the Wireless Switch with the Auto Channel scan field(0×50) set to 0xffff.

The Access Port will start with the first channel indicated in theAllowed Channels Field (0x2F), and sequentially process each channel asfollows:

-   -   1) The Access Port will “listen” for 200 milliseconds. The        Access Port will encapsulate each beacon heard on the channel in        a WISP header and send it to the Wireless Switch. The WISP frame        format will indicate the channel on which the beacon was heard,        as indicated in Table 61 and the received signal strength        (RSSI), as indicated in FIG. 63.    -   2) If radar is detected during ACS, a Status message will be        sent from the Access Port to the Wireless Switch with the Radar        Detect (0×53) indication.    -   3) At any point during ACS, the Wireless Switch may send a Reset        (Command 0x8002).    -   4) When all channels indicated in the Allowed Channels Field        (0x2F) have been processed by the Access Port, the Access Port        will send a Status message to the Wireless Switch with the Auto        channel scan field set to 0×FFFE. This informs the Wireless        Switch that that the scan process is complete and no more        beacons will forwarded.    -   5) When the Wireless Switch receives Status message indicating        “Scan Complete”, the Wireless Switch will evaluate the forwarded        beacons (and any Radar Detect indications). When the evaluation        is complete, the Wireless Switch will send a new Configuration        Packet to the Access Port that indicates the Selected Channel.    -   6) As soon as the newly indicated channel becomes effective, the        Access Port will send a Status message that indicates the new        Configuration Sequence number (0x51), and the number of the        assigned channel (0x50). At this point normal forwarding        operations continue.

Several messages sent by the Access Port have timeouts, repeatintervals, and differing behaviors depending on whether they timeout orreceive the expected response. The following is a summary. A Resetreturns the Access Port to the Access port Adoption Process.

Action after Expected Response Action after timeout waiting Message fromMessage from Repeat Expiration Expected for Expected Access PortWireless Switch Interval Time Response Response Hello Parent 1 Sec 10Sec Send LoadMe Send LoadMe with a non- with a NULL null Parent parentfield field LoadMe LoadImage 1 Sec 10 Sec Send next Reset LoadMe LoadMeLoadDone 1 Sec 10 Sec Send Reset DeviceInfo DeviceInfo Ack 1 Sec 10 SecSend Reset ConfigMe ConfigMe Configuration 3 Sec  9 Sec Start normalReset operation Status None 5 Sec None None None Unsolicited Heartbeat 1Sec 10 Sec Update Reset Heartbeat Info

The sequence number field in the Wireless Data Packet is used to detectpackets that have gotten out of order due to possible differing pathsthrough the switch fabric between a Wireless Switch and a Radio. Eachentity (Wireless Switch and Radio) must keep track of the sequencenumber of the last Wireless Data Packet that it received. If it receivesa Wireless Data Packet with a sequence number that is lower than thelast it received, it must discard that packet. Care must be taken toensure that this mechanism works through wrap-around of the sequencenumber back to zero.

While there have been described what are believed to be the preferredembodiments of the present invention, those skilled in the art willrecognize that other and further changes and modifications may be madethereto without departing from the spirit of the invention, and it isintended to claim all such changes and modifications as falls in thescope of the invention.

1. In a wireless local area network comprising a wireless switch whichcontrols the operation of an access port coupled to the wireless switchand which manages data communications with the access port, wherein saidaccess port comprises at least two radio portals each wirelesslycommunicating data to other mobile unit devices, a method forconfiguring one of the radio portals of said access port, the methodcomprising: downloading software from said wireless switch to saidaccess port for operation of said access port; signaling data from saidaccess port which identifies one of the radio portals of said accessport; and downloading data from said wireless switch to said access portto configure the identified radio portal of said access port.
 2. In awireless local area network comprising a wireless switch which controlsthe operation of an access port comprising at least two radio portalseach communicating data to other devices, a method for selecting achannel of operation for a selected one of said radio portals, themethod comprising: sequentially monitoring each of a plurality ofpossible channels using said selected radio portal to detect beaconsignals on said possible channels; forwarding received beacon signals toa wireless switch controlling operation of said access port having saidradio portal; analyzing said received beacon signals using said wirelessswitch to select a channel for operation of said selected radio portal;and sending a configuration message from said wireless switch to saidselected radio portal to configure said selected radio portal to operateon said selected channel.
 3. A method as specified in claim 2 whereinsaid wireless switch sends a control message to said access portdesignating said possible channels.
 4. A method as specified in claim 2wherein said access ports send signal strength data to said wirelessswitch with said received beacon signals.
 5. A method as specified inclaim 4 wherein said access port sends said received beacon signals tosaid wireless switch using a signal format identifying a channel onwhich said beacon signal was received.